perm filename LISP.BUG[BUG,LSP]10 blob
sn#669874 filedate 1982-07-26 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00071 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00011 00002 BUG-LISP and LISP-FORUM
C00012 00003 ∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
C00016 00004 ∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
C00019 00005 ∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
C00020 00006 ∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
C00022 00007 ∂11-Jan-82 0939 HES@MIT-AI
C00023 00008 ∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
C00026 00009 ∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
C00029 00010 ∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
C00030 00011 ∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
C00033 00012 ∂30-Jan-82 0728 kwh@MIT-AI minilisp
C00035 00013 ∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
C00043 00014 ∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
C00045 00015 ∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
C00047 00016 ∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
C00051 00017 ∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
C00053 00018 ∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
C00055 00019 ∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
C00057 00020 ∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
C00059 00021 ∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
C00060 00022 ∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
C00061 00023 ∂27-Feb-82 1153 EB@MIT-ML
C00062 00024 ∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
C00064 00025 ∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
C00067 00026 ∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
C00069 00027 ∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
C00072 00028 ∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
C00074 00029 ∂16-Mar-82 1643 George J. Carrette <GJC at MIT-MC>
C00075 00030 ∂23-Mar-82 1309 John G. Aspinall <JGA at MIT-MC> fixing, flooring, ceiling,...
C00077 00031 ∂11-Apr-82 1340 Glenn S. Burke <GSB at MIT-ML> assq compatibility with Maclisp
C00080 00032 ∂20-Apr-82 1831 Alan Bawden <ALAN at MIT-MC> &mumbles at all levels.
C00084 00033 ∂21-Apr-82 2203 JonL at PARC-MAXC Re: &mumbles at all levels -- BIND-ARGS
C00086 00034 ∂22-Apr-82 1136 George J. Carrette <GJC at MIT-MC> &mumbles at all levels.
C00088 00035 ∂22-Apr-82 1324 Stavros M. Macrakis <MACRAK at MIT-MC>
C00089 00036 ∂22-Apr-82 1614 Stavros M. Macrakis <MACRAK at MIT-MC>
C00090 00037 ∂02-May-82 2117 REM via SU-TIP (SSTATUS GCMAX 'ARRAY <n>) still not working
C00095 00038 ∂03-May-82 2054 Kent M. Pitman <KMP at MIT-MC>
C00097 00039 ∂05-May-82 1853 Leonard N Zubkoff <Zubkoff at Cmu-20c> Changes to Maclisp
C00100 00040 ∂05-May-82 2007 FEINBERG at CMU-20C Changes to Maclisp
C00102 00041 ∂06-May-82 1046 JONL at PARC-MAXC Of%Pdt
C00104 00042 ∂10-May-82 1215 OTADUY PEDRO J. <PJO at MIT-MC>
C00107 00043 ∂14-May-82 1432 David M. Krowitz <DAVID at MIT-AI>
C00109 00044 ∂14-May-82 1609 JONL at PARC-MAXC Assembling MacLISP under TOPS-10
C00111 00045 ∂26-May-82 2240 Alan Bawden <ALAN at MIT-MC> defstruct
C00112 00046 ∂03-Jun-82 0420 Dave Touretzky at CMU-10A bug in TOPS-20 MacLisp terminal i/o
C00114 00047 ∂05-Jun-82 0114 Alan Bawden <ALAN at MIT-MC> mis-use of fixpdl
C00116 00048 ∂05-Jun-82 1134 JonL at PARC-MAXC Re: mis-use of fixpdl
C00118 00049 ∂05-Jun-82 1350 Alan Bawden <ALAN at MIT-MC> #$&$&!#&!#! mis-use of fixpdl
C00121 00050 ∂05-Jun-82 1417 Alan Bawden <ALAN at MIT-MC> random output to MSGFILES in LAP files...
C00123 00051 ∂06-Jun-82 1228 Scott Robinson <SROBINSON at DEC-MARLBORO> LOAD-BYTE, DEPOSIT-BYTE bugs ....
C00126 00052 ∂11-Jun-82 1043 EIS@MIT-AI
C00127 00053 ∂11-Jun-82 1341 Stavros M. Macrakis <MACRAK at MIT-MC>
C00128 00054 ∂11-Jun-82 2014 Quux Proposed new FORMAT operator: ~U("units")
C00130 00055 ∂12-Jun-82 0025 Kent M. Pitman <KMP at MIT-MC>
C00131 00056 ∂12-Jun-82 0958 Quux More on ~U (short)
C00132 00057 ∂12-Jun-82 1125 George J. Carrette <GJC at MIT-MC>
C00133 00058 ∂14-Jun-82 2120 George J. Carrette <GJC at MIT-MC>
C00136 00059 ∂20-Jun-82 2020 ALAN at MIT-OZ OZ
C00137 00060 ∂20-Jun-82 2113 ALAN at MIT-OZ MacLisp on OZ
C00139 00061 ∂08-Jul-82 0005 David Chapman <Zvona at MIT-AI>
C00140 00062 ∂09-Jul-82 1641 PB ltype, lpend
C00141 00063 ∂10-Jul-82 1846 Jerry Roylance <GLR at MIT-AI> (OPEN 'FOO '(APPEND)) on TOPS-20
C00143 00064 ∂12-Jul-82 1137 JonL at PARC-MAXC Re: (OPEN 'FOO '(APPEND)) on TOPS-20
C00145 00065 ∂23-Jul-82 1446 Guy.Steele at CMU-10A MacLISP
C00148 00066 ∂24-Jul-82 1332 Glenn S. Burke <GSB at MIT-ML> macro/function competition
C00150 00067 ∂24-Jul-82 2259 George J. Carrette <GJC at MIT-MC> MacLISP
C00152 00068 ∂25-Jul-82 0032 Dave Touretzky at CMU-10A Re: MacLISP
C00154 00069 ∂25-Jul-82 1106 Dick@MIT-AI
C00155 00070 ∂25-Jul-82 1740 David Vinayak Wallace <GUMBY at MIT-AI> JSYS calls under twenex maclisp
C00156 00071 ∂25-Jul-82 2131 George J. Carrette <GJC at MIT-MC> JSYS calls under twenex maclisp
C00158 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
Date: 3 APR 1981 0908-EST
From: JerryB at MIT-AI (Gerald R. Barber)
Subject: Improving the LISP working environment by taking a lesson from...
To: SHRAGE at WHARTON-10, Deutsch at PARC-MAXC
CC: LISP-FORUM at MIT-AI, nil at MIT-MC
Date: 10 Nov 1980 10:41 PST
From: Deutsch at PARC-MAXC
To: SHRAGE at WHARTON (Jeffrey Shrager)
cc: lisp-forum, nil at MIT-MC
Re: Improving the LISP working environment by taking a lesson from...
1- In Interlisp, the Masterscope facility lets you easily find out what all your
functions, variables, etc. names are. In fact, it includes a powerful query
facility for discovering relationships in your program, much better than
anything in any other language or system I know. It is callable both from the
terminal (with pleasant English-like syntax) or from programs.
2- The SYSOUT facility in Interlisp makes it very cheap (in time) to create
checkpoints which you can resume from later. Many Interlisp users prefer the
APL "workspace" style, keeping a SYSOUT around to work in for days or weeks.
3- It's not simply a matter of "cover functions", different Lisp systems have
chosen to develop themselves in quite different directions. For example, Interlisp
has put tremendous emphasis on managing the programming process through
history retention, building up a data base of your code, etc., while MACLisp has
placed more emphasis on efficient compilation and certain kinds of system
simplicity. APL hasn't grown in ANY of these directions as far as I know. To
quote Joel Moses (approximately): "APL is a diamond -- you can't add anything
to it, even another diamond, without ruining its beauty. Lisp is a ball of mud:
you can keep adding more and more mud to it and its nature doesn't change." I
think it is precisely because Lisp is really almost like an assembly language for a
particularly interesting machine that it has been used to do such a tremendous
variety of things.
Here is a copy of a message that may be of interest.
∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
Date: 19 June 1981 00:44-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject: nested function definitions interfering with extensibility.
To: LISP-FORUM at MIT-AI
Date: 18 June 1981 10:37-EDT
From: George J. Carrette <GJC at MIT-MC>
This certainly true in the case of program editing in a
non-structured text-oriented way, but in a system with
more cooperation between program editor and compiler this
need not b`the case. I'm all for editing programs as text,
but I don't like representing them, storing them, as
a sequence of characters, i.e. in a purely syntactic manner.
Why? Because it severely limits program management to
purely syntactical levels.
The problem is not in editing at all. It is easy in any sort of
editor to edit the internal function definition and make no change to
the external one, and vice versa.
The problem comes when you try to store a file which, when loaded,
changes one but not the other. No editing is involved, just loading
of source or compiled files.
IRT Moon's suggestion:
Function specs like (:INTERNAL FOO BAR) for BAR within FOO make it
possible to redefine the internal function without changing the
external one. This is a good solution for that half of the problem.
But how do you redefine the external one without changing the internal
one?
∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
Date: 28 September 1981 09:07-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject: Suggested new lambda-list syntax
To: RMS at MIT-AI
cc: LISP-FORUM at MIT-AI
I prefer this proposal to the existing situation. Regards, Mark
∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
Date: 11 January 1982 12:21-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: backquote trivia, for you history fans.
To: Morrison at UTAH-20
cc: Lisp-Forum at MIT-AI
The PDP-10 Maclisp implementation of Backquote works at macroexpansion
time as you wanted. This was done for ease of GRINDEF'ing.
The Lispmachine implementation provides special synonyms for LIST, CONS,
LIST*, APPEND, etc, and uses a simple pattern matcher to create a cannonical
pretty form for GRINDEF. The NIL implementation uses code lifted from
code from which the Multics Maclisp backquote was derived, which is also
related in some way to the Lispmachine backquote.
In all implementations there are "car-position" markers for "," ",@" and ",."
and some simple entry to the "BACKQUOTIFY" function called by "`"
either at read or eval times.
Q: What is the deepest nesting of backquote found to arise in practice?
-gjc
∂11-Jan-82 0939 HES@MIT-AI
From: HES@MIT-AI
Date: 01/11/82 12:25:08
HES@MIT-AI 01/11/82 12:25:08
To: (BUG COMPLR) at MIT-AI
CC: ALAN at MIT-AI
The maclisp complr seems to generate the wrong stuff for the
code in ai:reason;foobar > ; in particluar the form
(setf (tms-support-status node) *in*)
turns into the wrong thing. Note that this code works interpretively.
My complr init loads lisp;struct fasl as does my lisp init in case this is relevant.
howie
∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
Date: 11 Jan 1982 1601-MST
From: Don Morrison <Morrison at UTAH-20>
Subject: clarification regarding backquote query
To: lisp-forum at MIT-AI
The sort of thing I had in mind for a complicated macro producing macro
was to have a macro producing macro foo consing up the final form, but
bits and pieces it stuffs in are being created by a function bar. The
value which foo finally returns will be some hairy conglomeration of
conses, lists, and appends, such as backquote is particularly good at
creating. But the pieces which bar creates will mostly be constant,
but sometimes I'd like bar to be able to return a piece which contains
a call on unquote, which unquote will be seen by the dynamically
surrounding backquote (i.e. in foo), rather than a lexically
surrounding one. Perhaps this is too complicated to be done clearly
(this description certainly is so complicated that I doubt it would
ever be clear) with backquote, but I seem to remember having created
such a beast where this seemed more perspicuous than the hard way.
Unfortunately I can't remember the exact example, and all the examples
I can now dream up don't warrant such a procedure; seems that in all my
toy examples simply adding an unquote in the caller and a backquote in
the callee works. Perhaps the "dynamic version" is never really
useful. And anyway, I gather from some of the replies that there are
functional entry points to the required pieces available in MACLISP and
friends, though I still don't know their names.
-------
∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
Date: 12 January 1982 17:38-EST
From: Jon L White <JONL at MIT-MC>
Subject: 'backquote' actions
To: Morrison at UTAH-20
cc: LISP-FORUM at MIT-MC
In MacLISP, the variable BACKQUOTE-EXPAND-WHEN determines
whether the reader-macro produces a minimal, standard, lisp form
which merely 'evaluates to the right thing', or a form with extra
evaluator macros inserted which correspond to the places where 'commas'
of various kinds appeared. Of course, the latter format 'evaluates
to the right thing' too.
The LISPM version produces a rather minimal form for evaluation, but using
internal function names rather than the standard lisp ones.
The point of having either the extra evaluator macros, or the special
internal function names, is so that a random piece of code which was
constructed up by the backquote macro can be re-parsed into a faithful
representation of the original input. The advantage of using evaluator
macros as opposed to internal subrs is that automatic code analyzers
don't have to know about these internal names (but rather would only
have to know about macroexpansion in general and the usual primitive
lisp subrs); the disadvantage of using the evaluator macro format is
that it takes an extra cons cell or so for each comma in the source input.
Note for example that there currently is no way to distinguish between the
internal forms of the following two functions:
(defun FIVE+ONE (x) '6)
(defun SIX (x) (quote 6))
whereas
(defun QUOTIFY-1 (x) `',x)
(defun QUOTIFY-2 (x) (list (quote QUOTE) x))
are distinguishable when BACKQUOTE-EXPAND-WHEN is set to EVAL (or
when other internal markers are left in).
∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
Date: 16 January 1982 14:32-EST
From: William G. Dubuque <WGD at MIT-MC>
Sender: BIL at MIT-MC
To: BUG-LISP at MIT-MC
The VECTOR package seems to break LEXPR-FUNCALL, e.g.
(load '((lisp)vector))
(lexpr-funcall 'list ()) =>
;SI:CLASS-TYPEP UNDEFINED FUNCTION IN UUO CALL
∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
Date: 26 Jan 1982 (Tuesday) 0211-EDT
From: FININ at WHARTON-10 (Tim Finin)
Subject: Interlisp and MacLisp (almost)
To: ejs at MIT-MC
cc: lisp-forum at MIT-MC
I've been working on a general inter-dialect Lisp translation system which
specializes in Interlisp to Franz Lisp (which is very close to MacLisp). It
is still undergoing developement. It includes a general rule driven
translator, a small set of pattern-action rules for translating Interlisp into Franz,
and a Interlispy run time environment for Frnaz. At Penn, we've opted for
a system that includes both translation and emulation. Some other efforts
I'm aware of include the following:
- The Franz group at Berkeley have some sort of Interlisp compatability
package for Franz.
- An extensive Interlisp to MacLisp translation system called MACLISPIFY
was written at SRI and used to transport some large systems. I can dig
up the details if you're interested.
- The Interlisp system includes the TRANSOR package for trnaslating Interlisp
code to other Lisp dialects. There is a set of rules for Interlisp to Maclisp,
although it is somewhat dated.
- There was a Interlisp to Maclisp translation system written by Jack Holloway
(I believe) and extended by Dave McDonnald. It was used to translate
the LUNAR system to MacLisp and LispMachine Lisp (I think).
- There is a group at Stanford on SUMEX that is trying to implement some of
the Interlisp packages (e.g. the RECORD package) in Franz.
i can supply more details on some of these efforts if you are interested.
Tim
∂30-Jan-82 0728 kwh@MIT-AI minilisp
From: kwh@MIT-AI
Date: 01/30/82 10:20:21
Subject: minilisp
kwh@MIT-AI 01/30/82 10:20:21 Re: minilisp
To: lisp-forum at MIT-MC, JoSH at RUTGERS
CC: KWH at MIT-AI
Bob Kirby at the University of Maryland has a nice LISP for the 11- it is a derivative
of Maryland LISP (which runs on UNIVAC's) which is derivative from Wisconson LISP...
It has a pretty printer, a MICROPLANNER, a structure editor, and a bunch of other
stuff. Bob Kirby is in the computer science department at Maryland, so you might
want to get in touch with him- the only problem with any LISP's for the 11 is that
you are intrinsically limited by that address space- (unless you hack
virtual memory, which is hairy but possible....)
Good luck,
Ken.
p.s. Does MIT have a copy of Rutger's extended addressing LISP? Can we get
one? Is there any documentation for it I could get a copy of?
∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
Date: 30 January 1982 16:55-EST
From: Jon L White <JONL at MIT-MC>
Subject: Comparison of "lambda-macros" and my "Two little suggestions ..."
To: KMP at MIT-MC, hic at SCRC-TENEX
cc: LISP-FORUM at MIT-MC, common-lisp at SU-AI
[Apologies for double mailings -- could we agree on a name for a
mailing list to be kept at SU-AI which would just be those
individuals in COMMON-LISP@SU-AI which are not also on LISP-FORUM@MC]
There were two suggestions in my note, and lambda-macros relate
to only one of then, namely the first one
FIRST SUGGESTION:
In the context of ((<something> . . .) a1 a2), have EVAL macroexpand
the part (<something> . . .) and "try again" before recursively
evaluating it. This will have the incompatible effect that
(defmacro foo () 'LIST)
((foo) 1 2)
no longer causes an error (unbound variable for LIST), but will rather
first expand into (list 1 2), which then evaluates to (1 2).
Note that for clarity, I've added the phrase "try again", meaning to
look at the form as see if it is recognized explicitly as, say, some
special form, or some subr application.
The discussion from last year, which resulted in the name "lambda-macros"
centered around finding a separate (but equal?) mechanism for code-expansion
for non-atomic forms which appear in a function place; my first suggestion
is to change EVAL (and compiler if necessary) to call the regular macroexpander
on any form which looks like some kind of function composition, and thus
implement a notion of "Meta-Composition" which is context free. It would be
a logical consequence of this notion that eval'ing (FUNCTION (FROTZ 1)) must
first macroexpand (FROTZ 1), so that #'(FPOSITION ...) could work in the
contexts cited about MAP. However, it is my second suggestion that would
not work in the context of an APPLY -- it is intended only for the EVAL-
of-a-form context -- and I'm not sure if that has been fully appreciated
since only RMS appears to have alluded to it.
However, I'd like to offer some commentary on why context-free
"meta-composition" is good for eval, yet why context-free "evaluation"
is bad:
1) Context-free "evaluation" is SCHEME. SCHEME is not bad, but it is
not LISP either. For the present, I believe the LISP community wants
to be able to write functions like:
(DEFUN SEMI-SORT (LIST)
(IF (GREATERP (FIRST LIST) (SECOND LIST))
LIST
(LIST (SECOND LIST) (FIRST LIST))))
Correct interpretation of the last line means doing (FSYMEVAL 'LIST)
for the instance of LIST in the "function" position, but doing (more
or less) (SYMEVAL 'LIST) for the others -- i.e., EVAL acts differently
depending upon whether the context is "function" or "expression-value".
2) Context-free "Meta-composition" is just source-code re-writing, and
there is no ambiguity of reference such as occured with "LIST" in the
above example. Take this example:
(DEFMACRO GET-SI (STRING)
(SETQ STRING (TO-STRING STRING))
(INTERN STRING 'SI))
(DEFUN SEE-IF-NEW-ATOM-LIST (LIST)
((GET-SI "LIST") LIST (GET-SI "LIST")))
Note that the context for (GET-SI "LIST") doesn't matter (sure, there
are other ways to write equivalent code but . . .)
Even the following macro definition for GET-SI results in perfectly
good, unambiguous results:
(DEFMACRO GET-SI (STRING)
`(LAMBDA (X Y) (,(intern (to-string string) 'SI) X Y)))
For example, assuming that (LAMBDA ...) => #'(LAMBDA ...),
(SEE-IF-NEW-ATOM-LIST 35) => (35 #'(LAMBDA (X Y) (LIST X Y)))
The latter (bletcherous) example shows a case where a user ** perhaps **
did not intend to use (GET-SI...) anywhere but in function context --
he simply put in some buggy code. The lambda-macro mechanism would require
a user to state unequivocally that a macro-defintion in precisely one
context; I'd rather not be encumbered with separate-but-parallel machinery
and documentation -- why not have this sort of restriction on macro usage
contexts be some kind of optional declaration?
Yet my second suggestion involves a form which could not at all be interpreted
in "expression-value" context:
SECOND SUGGESTION
Let FMACRO have special significance for macroexpansion in the context
((FMACRO . <fun>) . . .), such that this form is a macro call which is
expanded by calling <fun> on the whole form.
Thus (LIST 3 (FMACRO . <fun>)) would cause an error. I believe this
restriction is more akin to that which prevents MACROs from working
with APPLY.
∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
Date: 30 January 1982 17:39-EST
From: Jon L White <JONL at MIT-MC>
Subject: The format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
HIC has pointed out that the LISPM interpreter already treats the
format ((MACRO . f) ...) according to my "second suggestion" for
((FMACRO . f) ..); although I couldn't find this noted in the current
manual, it does work. I'd be just as happy with ((MACRO . f) ...) -- my
only consideration was to avoid a perhaps already used format. Although the
LISPM compiler currently barfs on this format, I believe there will be a
change soon?
The issue of parallel macro formats -- lambda-macros versus
only context-free macros -- is quite independent; although I
have a preference, I'd be happy with either one.
∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
Date: 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 11:38-EST
From: HIC at SCRC-TENEX
To: Jon L White <JONL at MIT-MC>
Cc: common-lisp at SU-AI, LISP-FORUM at MIT-MC
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
Re: Incredible co-incidence about the format ((MACRO . f) ...)
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Of course MACROEXPAND knows about it (but not the version you looked
at). I discovered this BUG (yes, BUG, I admit it, the LISPM had a
bug) in about 2 minutes of testing this feature, after I told the
world I thought it would work, and fixed it in about another two
minutes.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
JONL, you seem very eager to make this be your proposal -- so be it.
I don't care. However, it works on the Lisp Machine (it was a BUG
when it didn't work) to have (MACRO . foo) in the CAR of a form, and
thus it works to have a lambda macro expand into this.
Of course, Lambda Macros are the right way to experiment with the
functional programming style -- I think it's wrong to rely on seeing
the whole form (I almost KNOW it's wrong...). In any case, the Lisp
Machine now has these.
∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
Date: 17 February 1982 20:13-EST
From: Jon L White <JONL at MIT-MC>
Subject: SHARPM
To: ALAN at MIT-MC, GSB at MIT-MC
cc: BUG-LISP at MIT-MC
The additions to SHARPM which I mentiond about a month or so ago
are now installed in version 82 --
1) #nRddd format now works
2) #|...cruft...|# format now works, as per ALAN's request
3) the actual format of the /#-MACRO-DATALIST has been changed --
be advised if you ever depended upon it.
This change is only on MC right now, but I'll :INSTALL it "soon".
If anyone needs to back out of it, you should move LISP;SHARPM OFASL
into LISP;SHARPM FASL.
NOTE WELL: this change must correspondingly be coordinated with
the installation of EXTEND (from version 291 to 292), BITS (from
version 45 to 46), and VECTOR (from version 73 to 74) -- thus
an un-doing of SHARPM must also install LISP;* OFASL into LISP;* FASL
for these three files (for efficiency reasons, they depend upon
the format of that list).
∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
Subject: DO loses.
To: bug-complr at MIT-MC
I can't remember if this is a manifestation of a bug that bit me a couple
of times a few years ago, and which JONL said was too hard to fix, but
it sure surprised me. The only difference between foo and baz below is the
order of their supposedly side-effectless do steppers. I couldn't get it
to lose cdr-ing down a list, rather than using the array.
(*array 'arr 'fixnum 6)
(fillarray 'arr '(8 7 6 5 4 3 2))
(setq arr (get 'arr 'array))
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(print (list ch last))))
.lisp
LISP 2133
Alloc? n
*
(fasload lose fas)
34121
(foo arr)
(10 0)
(7 10)
(6 6)
(5 5) NIL
(baz arr)
(10 0)
(7 10)
(6 7)
(5 6) NIL
∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
Date: 22 February 1982 15:35-EST
From: 2Lt Eric J. Swenson <EJS at MIT-MC>
Subject: Interlisp and MacLisp (almost)
To: FININ at WHARTON-10
cc: LISP-FORUM at MIT-MC
Thanks for all your help with respect to Interlisp to Maclisp translators.
I am forwarding your message to ZHARTMAN@ISIE who works with the folks who
are interested in this endeavor. I'll let them handle it from there. I
would, however, like to saty in touch with the discussion, so please CC
your responses to their questions to me. Thanks. Also, I am interested in
the SRI project used to transport large systems. Please give me any
pointers to relevant information. Thanks -- Eric
∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
Date: 22 February 1982 16:31-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DO loses.
To: ROD at SU-AI
cc: BUG-complr at MIT-MC
Yes, this is that old hard-to-fix bug. The insertion of type declarations,
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0) (arraycall fixnum l i)))
((= i 5))
--> (declare (fixnum i last ch))
(print (list ch last))))
causes it to perform correctly. As a general rule declarations
for known-fixnum quantities, most especially inside loops as these
are, both stifle this bug and produce better code.
∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
Date: 23 February 1982 23:25-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: Closing Files.
To: FEINBERG at CMU-20C
cc: BUG-MACLISP at MIT-MC
For your information: File objects get closed when they are sweeped by
the garbage collector.
So all you need to do is have Emacs cause a GC in your Lisp job (or
any other Lisp job that has your file open)!
∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
Date: 26 February 1982 16:08-EST (Friday)
From: FEINBERG at CMU-20C
To: Bug-Maclisp at MC
Subject: DSK:
Howdy!
What is the status of fixing the the bug where someone
redefines DSK: to a list of things, and then Maclisp breaks? Another
user has just been screwed by this.
∂27-Feb-82 1153 EB@MIT-ML
From: EB@MIT-ML
Date: 02/27/82 12:58:24
EB@MIT-ML 02/27/82 12:58:24
To: JONL at MIT-MC
CC: (BUG MACLISP) at MIT-ML
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
Date: 27 February 1982 13:28-EST
From: Jon L White <JONL at MIT-MC>
To: eb at MIT-ML
cc: BUG-MACLISP at MIT-MC, feinberg at CMU-20C
EB@MIT-ML 02/27/82 12:58:24
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
They aren't "restricted" -- they are "frozen" accesses. I suspect that
Feinberg was confused. "Frozen" means that any number of readers can gain
access, but at most one writer can have APPEND access (I don't think you
can get random write access from within LISP). A file opened for ordinary
write access isn't visible in the catalogue until it is closed; maybe
that's what caused Feinberg to think it was "restricted". Any comments Neal?
P.S.: I'm using version 2129 at MIT-XX -- I notice that CMUC still has version
2122 from last fall; hopefully this won't make a diference, but I'll
send a note to Zubkoff to suggest the possibility of an update for CMUC.
∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
Date: 27 February 1982 15:05-EST
From: Jon L White <JONL at MIT-MC>
Subject: Compilation bug seen in DO loop
To: ROD at MIT-MC
cc: BUG-COMPLR at MIT-MC
Yes, the bug you noticed in "baz" below is a manifestation of the
local-variable-side-effected-by-fixnum-value bug, which you (and
a handful of others, notably GLR) discovered some time ago. The
simplest way to avoid this COMPLR problem is to declare such local
variable as FIXNUM, since it is the lack such declaration which
permits the bug to be seen; I've added a DECLARE in caps below to
indicate it. The declaration isn't necessary in "foo" since the
side-effects don't occur at the wrong time there, but it won't hurt
anything by having it (may even make the code marginally faster).
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
. . .
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
Date: 6 March 1982 22:04-EST
From: Alan Bawden <ALAN at MIT-ML>
Subject: how am I supposed to deal with this behavior?
To: BUG-COMPLR at MIT-ML
(defun test (x y)
(declare (fixnum x y))
(plus x y))
compiles into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADD 7 0 2)
(JSP T FXCONS)
(POPJ P)
()
This is incorrect. Nowhere did I specify that the sum of x and y was a fixnum
too.
Similarly:
(defun test (x y)
(plus (1+ x) (1+ y)))
Compile into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADDI 7 1)
(MOVE 10 0 2)
(ADDI 10 1)
(ADD 7 10)
(JSP T FXCONS)
(POPJ P)
()
Same bug.
∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
Date: 8 March 1982 10:51-EST
From: Jon L White <JONL at MIT-MC>
Subject: Wrong result
To: JSOL at USC-ECLC
cc: BUG-MACLISP at MIT-MC, Feinberg at CMU-20C
Date: Friday, 5 March 1982 09:19-PST
From: Jonathan Alan Solomon <JSOL at ECLC>
Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN
Seems to me that you can do it without "restricting the JFN". If you
open the file "restricted access", which uses the following bit
(excerpt from INFO's JSYS node):
B29(OF%RTD) Allow restricted access (i.e., allow
only one process to access the file).
You will get the desired results (no other process can hack the file),
while at the same time, INFORMATION (ABOUT) FILE will show it. Note,
this is for the OPENF jsys, not for the GTJFN jsys. The JFN is
available, but the file is locked.
I believe that what was desired was that the JFN be "protected" from
mungeing by random subforks, but that the file access *not* be restricted.
That is, it's ok for several forks/jobs to open the file for simultaneous
reading; the "frozen" access, by default, prohibits more than one user at
a time from gaining write/append access.
∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
Date: 8 March 1982 19:26-EST (Monday)
From: FEINBERG at CMU-20C
Subject: Restricted JFNs
To: Jonl at MC
CC: Bug-Maclisp at MC, Bug-Twenex at XX
Howdy!
Sorry, but you are inaccurate about Teco. Teco does indeed
have subforking capability (the FZ command). It uses this capability
to make Babyl work, and to make spelling correction possible. In
almost every case of the GTJFN command, you never specify the JFN
number you want, it finds a free JFN for you. I don't understand your
paranoia about this issue, however I feel a compromise can be reached.
Why not have a global flag which determines whether or not Maclisp
should use restricted JFNs? The default can even be paranoia mode.
This is very easy to implement efficiently. The only other objection
I can see for this is that no one wants to write the code for it. In
that case, I would be glad to implement this feature. ARYFIL is just
not an acceptable solution for me, and I am willing to do something
about it. I am not the only person who wants this fixed, either.
∂16-Mar-82 1643 George J. Carrette <GJC at MIT-MC>
Date: 16 March 1982 19:42-EST
From: George J. Carrette <GJC at MIT-MC>
To: SOLEY at MIT-MC, DCP at MIT-MC
cc: BUG-LISP at MIT-MC
Do you guys really expect to see bugs in the Maclisp reader fixed?
Geeeezzzz, I don't believe it. You can always write one yourself in
lisp, load EE:<GJC.LISP>READER.FASL, but then the tty-prescan won't
jive, so load KMP's rubout handler from EE:<GJC.LISP>RUB.FASL.
Don't like the evaluator? Well, replace that too.
Keep it up, and you soon run out of core.
∂23-Mar-82 1309 John G. Aspinall <JGA at MIT-MC> fixing, flooring, ceiling,...
Date: 23 March 1982 16:07-EST
From: John G. Aspinall <JGA at MIT-MC>
Subject: fixing, flooring, ceiling,...
To: BUG-LISP at MIT-MC
About a year or two ago I remember a discussion on LISP-DISCUSSION
about the various rounding functions, and a suggestion that someone
implement the set for MacLisp. There was a standard (IEEE ?) that
specified them. Was this ever done?
To remind - round towards zero : fix
- round towards -infinity : floor
- round towards +infinity : ceiling
- round away from zero : <I forget this one.>
John.
∂11-Apr-82 1340 Glenn S. Burke <GSB at MIT-ML> assq compatibility with Maclisp
Date: 11 April 1982 16:37-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: assq compatibility with Maclisp
To: JCMA at MIT-AI, BUG-lisp at MIT-MC
cc: BUG-LISPM at MIT-AI
Date: Saturday, 10 April 1982, 06:04-EST
From: JCMA@MIT-AI
Why do assq and assoc have to be incompatible with maclisp? That is,
why aren't assoc-careful and assq-careful the defaults?
----
It happens that Maclisp does not actually do assq-carefully, at least
not deliberately. It simply fails to check, and so can be fooled.
---- [transition to bug-lisp report] ----
uh oh... Even though i "knew" what maclisp was doing, i figured that
i would test it to see. The little cretin does assq-carefully in
(*RSET T) mode, and doesn't in (*RSET NIL) mode. What this means is
that the following happens in (*rset nil)
(assq nil '(0)) => 0
and in (*rset t) it yields NIL. The reason for this is that the CAR of
the fixnum 0 gives NIL. Similarly one can create other fixnums (and flonums)
which will fool assq for any other object.
So much for features. This sounds like a totally useless, misleading,
and inconsistent Maclisp feature. It is a waste of the address space
which someone has been trying hard to conserve. If it is going to check,
it should bitch, it shouldn't conditionally do the wrong thing.
∂20-Apr-82 1831 Alan Bawden <ALAN at MIT-MC> &mumbles at all levels.
Date: 20 April 1982 21:27-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: &mumbles at all levels.
To: BUG-LISPM at MIT-MC
cc: LISP-FORUM at MIT-MC, DULCEY at MIT-ML
Date: 04/19/82 22:30:38
From: DULCEY at MIT-ML
(defmacro foo ((one &optional (two ''two)) &body three)
`(list ,one ,two ',three))
>>ERROR: &OPTIONAL -- unrecognized & keyword in DEFMACRO.
While in the function ...
This probably isn't defined as working. However, it would be useful if
it did.
Indeed, this is currently defined to be an error. Would anyone object if I
actually made it act as it obviously should? I would like to fix this, and
simultaneously introduce a general tool for performing macro body parsing.
Proposed new special form: BIND-ARGUMENTS
example:
(bind-arguments ((a &optional (b *b*)) (foo) (barf))
b o d y)
(approximately)==>
(let ((gensym (foo)))
(if (not (and (<= (length gensym) 2)
(>= (length gensym) 1)))
(barf))
(let ((a (car gensym))
(b (if (< (length gensym) 2) *b* (cadr gensym))))
b o d y))
Now, you probably would never need a macro like this directly, but suppose you
had to write defmacro yourself:
(defmacro defmacro (name pattern &body body)
(let ((v (gensym)))
`(macro ,name (,v)
(bind-arguments (,pattern (cdr ,v) (ferror nil "Bad syntax: ~S" ,v))
,@body))))
That was easy wasn't it! So easy that ANYONE can do it. This seems to be the
right tool for bringing &mumble-argument-parsing to the masses.
Now I already have a working one of these (amazingly usefull in the right
situations I must add), and I would like to install it in the LispMachine as
the way defmacro etc work. This would have two noticeable effects:
1) &keywords would start to work at all levels in defmacro patterns. I presume
no one objects to this?
2) &list-of STOPS working... (finally I got around to the screw). Does ANYONE
use this feature? I could try and duplicate it, but if noone uses it (as I
suspect) I would rather just flush it. What to LispMachine people think?
(If no one raises objection, I'll ask info-lispm next.)
Unnoticeable effect:
3) The code produced by defmacro would be smaller and faster. (You would be
appalled at the code defmacro currently turns out.)
∂21-Apr-82 2203 JonL at PARC-MAXC Re: &mumbles at all levels -- BIND-ARGS
Date: 21 Apr 1982 21:57 PST
From: JonL at PARC-MAXC
Subject: Re: &mumbles at all levels -- BIND-ARGS
In-reply-to: ALAN's message of 20 April 1982 21:27-EST
To: Alan Bawden <ALAN at MIT-MC>
cc: Guy.Steele@CMUA,LISP-FORUM@MIT-MC
Wasn't there a lot of discussion about 6 months to a year ago about
having LET accept &mumbles "at lots of levels"? When you say
"at all levels" do you mean that BIND-ARGS will also destructure?
If progress on LET is going to be forever bogged down in the red tape,
then how about doing BIND-ARGUMENTS at least one of the two ways
proposed for destructuring (and since you are using the &optional words,
you have more-or-less selected the data-pattern format rather than the SETF
format).
∂22-Apr-82 1136 George J. Carrette <GJC at MIT-MC> &mumbles at all levels.
Date: 22 April 1982 14:31-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: &mumbles at all levels.
To: ALAN at MIT-MC
cc: BUG-LISPM at MIT-MC, LISP-FORUM at MIT-MC, BUG-LISP at MIT-MC,
DULCEY at MIT-ML
Go for it! Indeed, for the destructuring implementation for NIL I
implemented &mumbles at all levels, and it was easier, cleaner, and
produced considerably less code per DEFMACRO than using the other
methods.
For example, the following defmacro:
(defmacro g ((a b (c d)) &optional e)
(foo a b c d e))
compiles into 42 pdp-10 instructions using the technology presently
provided in Maclisp, but only 7 pdp-10 instructions using the technology used
in NIL (inside the compilation environment in pdp-10 maclisp which *was* used
to compile the cross compiler).
-gjc
∂22-Apr-82 1324 Stavros M. Macrakis <MACRAK at MIT-MC>
Date: 22 April 1982 16:24-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC
(defun f (a b)
(let ((x (f1 a)) (y (f2 a)))
(cond ((not x) y)
((eq x y) y)
((eq y x) y)
((eq x y) x)
((eq y x) x)))))))
(which admittedly is weird code) produces a whole succession of code
sequences like:
caxx
jrst g1
jrst g2
g1:
while the same code without the Let doesn't.
∂22-Apr-82 1614 Stavros M. Macrakis <MACRAK at MIT-MC>
Date: 22 April 1982 19:11-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC
(defun sdfsdf (wer) (cond ((null wer) nil)))
compiles to
push p,1
sub p,[1,,1]
jrst pdlnkj
which is wrong and weird. I've noticed that complr is doing a lot of
unnecessary stack saves and pdlnmk's lately. Complr used to produce
really beautiful code. What's happened?
∂02-May-82 2117 REM via SU-TIP (SSTATUS GCMAX 'ARRAY <n>) still not working
To: BUG-PLISP
Do you have any plans to ever look at this bug?
(It's been over 2 years!)
∂25-Dec-79 1805 RPG -- [PLISP: (SSTATUS GCMAX 'ARRAY <n>) ignored]
I'm going to try to investigate this a little over the next few days,
if possible.
-rpg-
;;Here's a transcript of the bug still present in 1982:
.DA
Sunday 2-May-82 20:48 61F 16C
.R PLISP
LISP 2133
Alloc? N
*
↑D ;Turns on printout for GC and allocation statistics
(GC)
;GC DUE TO USER
; 403[25%] LIST, 770[98%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 465[30%] SYMBOL, 756[96%] ARRAY WORDS FREE
NIL
(STATUS GCMAX 'ARRAY) (STATUS SPCSIZE 'ARRAY)
1000
1000
(SSTATUS GCMAX 'ARRAY 10000)
T
;If this were working correctly, it wouldn't do a GC until ARRAY space
; had reached 10000. But as you see it's keeping ARRAY space at 1000-2000
; and doing GC over and over against my desires:
(PROG () L (SETQ A (ARRAY NIL NIL 5)) (GO L))
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 3000 WORDS
;GC DUE TO ARRAY SPACE
; 371[16%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 2[0%] ARRAY WORDS FREE
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 4000 WORDS
;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 2000 WORDS
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
↑C
.REE
?GQUIT*
(STATUS SPCSIZE 'ARRAY)
2000
(STATUS GCMAX 'ARRAY)
10000
;As you see, ARRAY size is still 2000 even though it's been doing GCs which
; weren't supposed to be done until it reached 10000.
;Now for comparison, LIST space does work as it should, here's a transcript:
(STATUS GCMAX 'LIST) (STATUS SPCSIZE 'LIST)
40000
4000
;Notice it's adding new segments without doing any GC, until 40000 is reached:
(PROG () L (SETQ S (CONS NIL NIL)) (GO L))
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 5000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 6000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 7000 WORDS
;... Transcript edited for brevity ...
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 35000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 36000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 37000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 40000 WORDS
;GC DUE TO LIST SPACE
; 35342[92%] LIST, 762[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 460[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO LIST SPACE
; 35342[92%] LIST, 762[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 460[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;As you see above, it waited until size reached 40000 before starting
; to do GCs.
↑C
.DA
Sunday 2-May-82 20:53 61F 16C
∂03-May-82 2054 Kent M. Pitman <KMP at MIT-MC>
Date: 3 May 1982 23:53-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
(setq a (open 'tty: '(in fixnum tty single)))
(in a)↑C
;(IN #FILE-IN-|TTY:* *|-70776) EOF - IN
IN does not see control-C in a file as an EOF, I don't know why it should
on the TTY. In particular, if the person has the tty open, he ought to know
he does anyway. If he wants to interpret ↑C as an eof, it seems easy for him
to do so. I imagine it is probably irritating to anyone that tries this that
↑C is trapped in this way ...
I don't need this to work for code, so it's not worth fixing for now unless
it is bothering someone else. I just thought I'd note the problem.
-kmp
∂05-May-82 1853 Leonard N Zubkoff <Zubkoff at Cmu-20c> Changes to Maclisp
Date: Wednesday, 5 May 1982 21:48-EDT
From: Leonard N Zubkoff <Zubkoff at Cmu-20c>
To: Steele at CMU-20C, Fahlman at CMU-20C, Jonl at Parc-Maxc,
Bug-Lisp at mc
Subject: Changes to Maclisp
We've recently discovered a peculiar interaction between MacLisp and the
migration system program (reaper). It seems that some .fasl files that were
being accessed by MacLisp frequently were not having their last-read dates
updated properly, causing them to be migrated and thus making MacLisp unusable
until they were restored.
Our system programmer, Aaron Wohl, postulates that this is caused by MacLisp's
first opening a file with the do-not-update-read-date bit set (Of%Pdt) and then
actually opening the file for reading. Apparently, the monitor is then failing
to update the read date on the second file opening as well. Searching through
the Lisp sources, it appears that the only place such an Openf% is ever used is
in the function FASLP; also, it seems highly likely that most uses of FASLP
would be immediately followed by actually reading the file.
In order to alleviate this problem, I've built and installed Lisp version 2130
on CMUC using a modified QIO.mid with the following changes:
(1) Of%Pdt is no longer set on the Openf% in FASLP.
(2) All GtJfn% calls have had the Gj%Acc removed, so that the files are visible
(this change in response to discussions with Jonl indicating that this would be
a good idea).
If whoever is responsible for maintaining the master Lisp sources would make
these changes there as well, it would be appreciated. Alternatively, just
ftp the file Ps:<MacLisp>Qio.mid.751 from CMUC.
Leonard Zubkoff
∂05-May-82 2007 FEINBERG at CMU-20C Changes to Maclisp
Date: 5 May 1982 22:29-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Leonard N Zubkoff <Zubkoff at CMU-20C>
CC: Bug-Lisp at MC, Fahlman at CMU-20C
Subject: Changes to Maclisp
--Text follows this line--
Howdy!
I believe the Jonl has already updated maclisp wrt Gj%Acc.
As for Of%Pdt, I suspect that the monitor bug should be
fixed, not Maclisp. Certainly checking to see if a file is a FASL
file should not constitute reading it. I suggest that we just run
with your modified version of Maclisp on CMUC until Aaron Wohl gets
around to fixing the bug. Also, perhaps there is a way to prevent the
reaper from reaping the <MACLISP> directory, which I think is a bad
idea in the first place. It is hard enough to keep Maclisp running
without files magically disappearing onto tape. Unless a significant
number of other sites are encountering this problem, we should stick
with a local fix.
--Chiron
Subject:
∂06-May-82 1046 JONL at PARC-MAXC Of%Pdt
Date: 6 MAY 1982 1041-PDT
From: JONL at PARC-MAXC
Subject: Of%Pdt
To: zubkoff at CMUC, feinberg at CMUC
cc: fahlman at CMUC, bug-lisp at MIT-MC
Feinberg's note was quite right -- I've already edited the MC
sources for the Gj%Acc change. I also agree with him that no change
should be made in the Lisp semantics for what appears to be
a CMU-specific bug (failure to update read date doesn't occur
at XX). Perhaps most TOPS-20 systems do reap the <maclisp> directory,
but the corresponding directory on the ITS machines is maintained
"by hand" for just the reasons noted -- the
difficulty of maintiaining a coherent systems when
critical, but seldom referenced, parts disappear randomly.
∂10-May-82 1215 OTADUY PEDRO J. <PJO at MIT-MC>
Date: 10 May 1982 15:11-EDT
From: OTADUY PEDRO J. <PJO at MIT-MC>
To: BUG-LISP at MIT-MC
This is Pedro at ORNL.
I am trying to get Maclisp version 2022 up in our KA10-TOPS10.
I have found bugs in array related functions.
FILLARRAY,FILEPOS,IN and LOADARRAYS have fatal BUGs in this version.
I have observed that they are not present in the version presently
running at your MC site. Can anyperson give me the patchup recepy?
FILEPOS symptoms:
Let 0=<n<(FILEPOS fi) ...then... (FILEPOS fi n) gives UUO error @440410
FILLARRAY symptoms:
Let (FILEPOS fi)=0 be case #1 ,
(FILEPOS fi)>0 be case #2 ,
(FILEPOS fidump)=3 be case #3 where fi is a FIXNUM file OPen for INput
created by (FILLARRAY fi 'ARRAYX) , and fidump is same but created by
a DUMPARRAYS command.
THEN...
(FILLARRAY 'ARRAYN fi) Halts at 444066 for both cases #1 and #2...but
on reentering 'ARRAYN shows to be unchanged in case #1 ,while
'ARRAYN shows the correct info in case #2.
ON the other hand (?) case #3 works satisfactorily.
LOADARRAYS was not working at all.Upon some study i found IN to be the culprit.
Replacing the JUMPN 10,452756 @453015 (inside IN) with a JUMPG ... instruction did fix LOADARRAYS. Now i don't know if this is Kosher but it works.
Gratious reader of this missive...if you can help with these bugs and do so I will be most grateful. Also, are there any other bugs I should be aware
of?
THanks. sincerely..pedro.
∂14-May-82 1432 David M. Krowitz <DAVID at MIT-AI>
Date: 14 May 1982 16:51-EDT
From: David M. Krowitz <DAVID at MIT-AI>
To: BUG-LISP at MIT-AI
When I try to compile lisp 2129 using the TOPS10 switch, I get the
following error messages:
sharp1+1 3060 2. 37-022 ###### HOW TO SHARE WITH "PURQIO" FILE?
gethgh 3107 0. 38-079 VECALL Undefined
I am using midas 428 running under tops10 version 6.03A on a regular
KA10 (ie. no paging hardware has been added). In addition to these error
messages, the lisp version number is typed out as 687194. I am able
to load the relocatable binary file which is provided with the lisp
distribution tape, but it seems to run out of memory space very quickly.
typing something like (ARRAY FOO T 5000.) usually result in
a "can't get core" message. Trying to load COMPLR.FAS runs into the same
problem.
--david krowitz
∂14-May-82 1609 JONL at PARC-MAXC Assembling MacLISP under TOPS-10
Date: 14 MAY 1982 1607-PDT
From: JONL at PARC-MAXC
Subject: Assembling MacLISP under TOPS-10
To: david at MIT-AI
cc: BUG-LISP at MIT-MC
Several mesages will be printed out that do not reflect true
"errors", but were merely inserted in the source code so that
the lisp maintainers would be reminded of some lacunae
in the non-ITS versions. The comment about "###### HOW TO SHAR WITH PURQIO FILES"
is no problem.
On the other hand, the VECALL undefined is a true error, and is
probably symptomatic of some failure to conditionalize code for
the SAIL-specific assembly (SAIL is a variant of TOPS-10).
It's generally true that non-virtual-memory TOPS-10 sites have
troubles running anyything interesting in MacLISP; a total
core allotment of about 100K would be reasonable for the Compiler,
and as I recall, many sites restrict the random user to about
40K or so. See if you can get a larger allotment "late at nite".
∂26-May-82 2240 Alan Bawden <ALAN at MIT-MC> defstruct
Date: 27 May 1982 01:39-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: defstruct
To: INFO-MACLISP at MIT-MC
I have just installed a new defstruct on all the ITS sites. There are many bug
fixes, and some new features. The file LIBDOC;STRUCT NEWS contains a brief
summary of the changes (there are no incompatibilities with the previous
version). If there are any problems, the old FASL can be found in
MC:ALAN;STRUCT OFASL.
∂03-Jun-82 0420 Dave Touretzky at CMU-10A bug in TOPS-20 MacLisp terminal i/o
Date: 2 June 1982 2223-EDT
From: Dave Touretzky at CMU-10A
To: bug-lisp at MIT-MC
Subject: bug in TOPS-20 MacLisp terminal i/o
The file <MACLISP>CSTEP.FASL on CMU-20C contains a CMU-modified version
of the Rich stepper. It demonstrates a bug in TOPS-20's i/o routine for
reading single characters from the terminal. To check out this bug you
should load the CMU programming environment described in the files
<MACLISP>LISP.INI and <MACLISP>COMMON.INI on CMU-20C.
One especially pertinent item: we run with (status linmode t).
After starting up a fresh Lisp, do the following:
(STEP T) ;load CMU's stepper
(PLUS 1 2)<space><cr> ;note that stepper isn't reading a space alone -- it
;needs a <cr> to terminate the read (bogus!)
↑C
START ;restart Lisp
(STEP T) ;try the stepper again
(PLUS 1 2)<space> ;now it can read <space> by itself!
↑G ;quit to toplevel again
(STEP T) ;try the stepper one more time
(PLUS 1 2)<space><cr> ;now it can't read <space> !!!!
Clearly the terminal initialization done by START and that done
by ↑G is not the same. I claim that only START does the initialization
correctly.
-- Dave Touretzky
∂05-Jun-82 0114 Alan Bawden <ALAN at MIT-MC> mis-use of fixpdl
Date: 5 June 1982 04:12-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: mis-use of fixpdl
To: BUG-COMPLR at MIT-MC
(abs (remainder (cond ...
(... (lsh atom 0))
(t (maknum atom)))
*hashtable-size*))
compiles into:
(MOVE 7 @ 0 P)
(PUSH FXP 7)
(MOVEI 1 0 FXP)
(SUB FXP (% 0 0 1 1)) ;???
(JRST 0 G0010)
G0012
(MOVE 7 0 P)
(PUSH FXP 7)
(MOVEI 1 0 FXP)
(SUB FXP (% 0 0 1 1)) ;???
G0010
(MOVE 2 (SPECIAL *HASHTABLE-SIZE*))
(CALL 2 'REMAINDER)
(CALL 1 'ABS)
The whole function can be found in the file LSPMAI;ALAN FIXPDL.
∂05-Jun-82 1134 JonL at PARC-MAXC Re: mis-use of fixpdl
Date: 5 Jun 1982 11:32 PDT
From: JonL at PARC-MAXC
Subject: Re: mis-use of fixpdl
In-reply-to: ALAN's message of 5 June 1982 04:12-EDT
To: Alan Bawden <ALAN at MIT-MC>
cc: BUG-COMPLR at MIT-MC
Sigh, this is an old one, and not likely to go away easily, although one
can rather try to avoid it. Could it be that the part of your source
code (omitted in your original msg) had some COND clauses which
were not discernably numeric?
(abs (remainder (cond *...*
(... (lsh atom 0))
(t (maknum atom)))
*hashtable-size*))
The *...* is the part in question.
∂05-Jun-82 1350 Alan Bawden <ALAN at MIT-MC> #$&$&!#&!#! mis-use of fixpdl
Date: 5 June 1982 16:47-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: #$&$&!#&!#! mis-use of fixpdl
To: JonL at PARC-MAXC
cc: BUG-COMPLR at MIT-MC
Date: 5 Jun 1982 11:32 PDT
From: JonL at PARC-MAXC
Sigh, this is an old one, and not likely to go away easily, although one
can rather try to avoid it. Could it be that the part of your source
code (omitted in your original msg) had some COND clauses which
were not discernably numeric?
(abs (remainder (cond *...*
(... (lsh atom 0))
(t (maknum atom)))
*hashtable-size*))
The *...* is the part in question.
The missing clause was ((fixp atom) atom). The possibility that atom might be
a bignum is the reason for calling remainder rather than \. Indeed, I am
finding it rather difficult to rearrange my code to make complr do this right.
Currently I have it producing
(MOVE 7 0 P)
(PUSH FXP 7)
(MOVEI 1 0 FXP)
(SUB FXP (% 0 0 1 1))
G0012
(JSP T PDLNMK)
for the call to maknum. If I wasn't looking at the LAP so carefully now I
would probably never notice this, since I would have to be screwed by a rather
unlikely interrupt. I guess I have to separate the bignum case from the fixnum
cases to get this to work right?
∂05-Jun-82 1417 Alan Bawden <ALAN at MIT-MC> random output to MSGFILES in LAP files...
Date: 5 June 1982 17:15-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: random output to MSGFILES in LAP files...
To: BUG-COMPLR at MIT-MC
Sorry about the message I just sent, I spazzed and typed a ↑C by accident.
File TEST contains just:
(herald test)
File TEST1 contains:
(declare (load 'test))
(defprop test t test)
(defprop foo t foo)
Compiling TEST1 works just fine normally. However, if you compile it with the
switch -K so that you get to look at the LAP file, then the lap file looks
like:
'(THIS IS THE LAP FOR ((DSK ALAN) TEST1 /2))
'(COMPILED BY LISP COMPILER /936 COMAUX /25 PHAS1 /86 MAKLAP /80 INITIA /118)
;COMPILED ON SATURDAY, JUNE 5, 1982, AT 5:07 PM
;Loading TEST 2(DEFPROP TEST T TEST)
(DEFPROP FOO T FOO)
Which doesn't assemble into the same thing since the herald message has
commented out the first defprop!
BARF!
∂06-Jun-82 1228 Scott Robinson <SROBINSON at DEC-MARLBORO> LOAD-BYTE, DEPOSIT-BYTE bugs ....
Date: 6 Jun 1982 1526-EDT
From: Scott Robinson <SROBINSON at DEC-MARLBORO>
To: bug-lisp at MIT-MC
Subject: LOAD-BYTE, DEPOSIT-BYTE bugs ....
Message-ID: <"MS10(2055)+GLXLIB1(1056)" 11829722457.14.254.71284 at DEC-MARLBORO>
I have discovered a few bugs in LOAD-BYTE and DEPOSIT-BYTE generation
by SRCTRN 20. They are:
1) LOAD-BYTE didn't evaluate the shift displacement in the generated code.
This was a typeo.
2) DEPOSIT-BYTE didn't shift the byte to be deposited before anding with
the 'hole' mask.
The following is a SRCCOM of the fixes to SRCTRN 20 to eliminate these
problems. (How do I get the MIT-MC sources updated?)
Thanks,
Scott Robinson
(617) 467-6988
SROBINSON@DEC-MARLBORO
; SRCTRN.LSP.21 & SRCTRN.LSP.20 6-Jun-82 1451 PAGE 1
LINE 12, PAGE 1
1) (setq |verno| (cond ((fixp x) file) ('/21)))))
1)
LINE 12, PAGE 1
2) (setq |verno| (cond ((fixp x) file) ('/20)))))
2)
LINE 65, PAGE 3
1) (setq word `(LSH ,word (- ,position))))
1) `(BOOLE 1 ,word ,byte-mask))))
LINE 65, PAGE 3
2) (setq word `(LSH ,word ,(- position))))
2) `(BOOLE 1 ,word ,byte-mask))))
LINE 77, PAGE 3
1) ((let ((lsher `(LSH ,val ,position))
1) (masked-word `(BOOLE 4 ,word ,shift-mask)))
1) (if (and nval (= nval 0))
LINE 77, PAGE 3
2) ((let ((masked-word `(BOOLE 4 ,word ,shift-mask)))
2) (if (and nval (= nval 0))
LINE 84, PAGE 3
1) `(BOOLE 1 ,lsher ,shift-mask)))))))))))
1) (ldbp `(BOOLE 1 (LSH ,word (- ,position)) ,byte-mask))
LINE 83, PAGE 3
2) `(BOOLE 1 ,val ,shift-mask)))))))))))
2) (ldbp `(BOOLE 1 (LSH ,word (- ,position)) ,byte-mask))
--------
∂11-Jun-82 1043 EIS@MIT-AI
From: EIS@MIT-AI
Date: 06/11/82 12:32:51
EIS@MIT-AI 06/11/82 12:32:51
To: INFO-MACLISP at MIT-MC
IS THERE A Maclisp function which will unwind
the stack WITHOUT returning to top level?
(or, is there some simple way to achieve the
same effect which I'm overlooking)?
Thanks.
Marc
∂11-Jun-82 1341 Stavros M. Macrakis <MACRAK at MIT-MC>
Date: 11 June 1982 16:39-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC
(defun xx (a) (let ((q a)) (cond ((eq q a) (cdr q)) (t q))))
produces a jrst .+1 . I thought Complr didn't do that, ever.
∂11-Jun-82 2014 Quux Proposed new FORMAT operator: ~U("units")
Date: 11 June 1982 2233-EDT (Friday)
From: Quux
To: bug-lisp at MIT-AI, bug-lispm at MIT-AI, common-lisp at SU-AI
Subject: Proposed new FORMAT operator: ~U("units")
Sender: Guy.Steele at CMU-10A
Reply-To: Guy.Steele at CMU-10A
Here's a krevitch that will really snork your flads. ~U swallows
an argument, which should be a floating-point number (an integer or
ratio may be floated first). The argument is then scaled by 10↑(3*K)
for some integer K, so that it lies in [1.0,1000.0). If this
K is suitably small, then the scaled number is printed, then a space,
then a metric-system prefix. If not, then the number is printed
in exponential notation, then a space. With a :, prints the short prefix.
Examples:
(FORMAT () "~Umeters, ~Uliters, ~:Um, ~:UHz" 50300.0 6.0 .013 1.0e7)
=> "50.5 kilometers, 6.0 liters, 13.0 mm, 10.0 MHz"
And you thought ~R was bad!
∂12-Jun-82 0025 Kent M. Pitman <KMP at MIT-MC>
Date: 12 June 1982 03:23-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-MACLISP at MIT-MC
I replied to EIS@AI re stack unwinding, also mentioning that INFO-MACLISP was
the wrong place for him to send the query.
∂12-Jun-82 0958 Quux More on ~U (short)
Date: 12 June 1982 1119-EDT (Saturday)
From: Quux
To: bug-lisp at MIT-AI, bug-lispm at MIT-AI, common-lisp at SU-AI
Subject: More on ~U (short)
Sender: Guy.Steele at CMU-10A
Reply-To: Guy.Steele at CMU-10A
I forgot to mention that the @ flag should cause scaling by powers of 2↑10
instead of 10↑3: (format () "~Ubits, ~:Ub, ~@Ubits, ~:@Ub" 65536 65536 65536 65536)
=> "65.536 kilobits, 65.536 Kb, 64.0 kilobits, 64.0 Kb"
--Q
∂12-Jun-82 1125 George J. Carrette <GJC at MIT-MC>
Date: 12 June 1982 14:23-EDT
From: George J. Carrette <GJC at MIT-MC>
To: MACRAK at MIT-MC
cc: BUG-COMPLR at MIT-MC
Date: 11 June 1982 16:39-EDT
From: Stavros M. Macrakis <MACRAK>
To: BUG-COMPLR
(defun xx (a) (let ((q a)) (cond ((eq q a) (cdr q)) (t q))))
produces a jrst .+1 . I thought Complr didn't do that, ever.
I hate to have to break the news to you, but I seriously doubt if
any of the many bug notes you have been sending to BUG-COMPLR and
BUG-LISP of late will ever see the light of day as bug fixes.
∂14-Jun-82 2120 George J. Carrette <GJC at MIT-MC>
Date: 15 June 1982 00:16-EDT
From: George J. Carrette <GJC at MIT-MC>
To: PJO at MIT-MC
cc: BUG-LISP at MIT-MC
Date: 14 June 1982 18:01-EDT
From: OTADUY PEDRO J. <PJO>
To: BUG-LISP
Nobody has responded to my report on FILLARRAY etc bugs. Does anybody
care?????
Yes. I heard that this is one of the things "fixed in the new error system."
But seriously, (maybe thats too much of an inside joke) people do care if
local programs and research groups running on local systems, TOPS-20 and ITS,
are hurt by maclisp bugs. The only people to maintain maclisp at MIT now
are those who support systems such as BRANDX and MACSYMA, and/or still
maintain serious personal working environments in Maclisp. Maclisp is also
used to support a Scheme system used in teaching. [One big local use of
Maclisp, to support the NIL cross-compiler, is "no more" because NIL is
perfectly happy running on the VAX where it should. This might also
imply something about support for many features which were added as
"NIL compatibility," especially since none of the "NILCOM" code was
ever used in NIL.]
Note: JONL who as the maintainer of pdp10 maclisp used to fix bugs
and add other things, is no longer at MIT.
In summary, people do care. There are good hackers at MIT that want to
make sure that pdp-10 maclisp has a long and useful "old age."
It make take a couple months before you see any particular action though.
-gjc
∂20-Jun-82 2020 ALAN at MIT-OZ OZ
Date: Sunday, 20 June 1982 22:47-EDT
From: ALAN at MIT-OZ
To: bug-lisp at mc
Subject:OZ
In the currently installed MacLisp on OZ (status site) returns TOPS-20, which
is indeed the second to the last element on the (status features) list.
(status feature OZ) returns NIL. What has to be done to get the site-name to
appear there?
I'd be happy to learn how to go about installing MacLisps on a TOPS-20 site
since I'll be a user of it on OZ.
-------
∂20-Jun-82 2113 ALAN at MIT-OZ MacLisp on OZ
Date: Sunday, 20 June 1982 23:46-EDT
From: ALAN at MIT-OZ
To: bug-lisp at MIT-OZ, bug-oz at MIT-OZ
Subject:MacLisp on OZ
Would it be useful to move the LIBLSP directory from ITS to OZ? Some of the
more useful things are already present in <maclisp> (such as STEP and APROPOS)
but people may have come to depend on some of the other, less commonly used
utilities. Also people are liable to have things like (load '((liblsp) frob))
in their code, and it would be nice to make the transition easy for them. (I
just moved the DRIBBLE package into <maclisp>, it has a tendency to name files
"dribbl.>.1", but it is still useful.)
On EE there is a LISP: logical-name for ps:<maclisp>. I presume this is so
that the MacLisp specific hack where ((LISP) FOO) gets translated to
((PS MACLISP) FOO) by virtue of the symbol LISP having a PPN property of
(PS MACLISP) will work in the entire Twenex environment. This sounds like a
good idea, perhaps OZ should have it to.
-------
∂08-Jul-82 0005 David Chapman <Zvona at MIT-AI>
Date: 7 July 1982 14:54-EDT
From: David Chapman <Zvona at MIT-AI>
To: BUG-LISP at MIT-AI, BUG-GPRINT at MIT-AI, BUG-ZWEI at MIT-AI
progw and progv have bodys. Zwei, GPRINT, and GRIND-TOP-LEVEL none of
them realize this.
∂09-Jul-82 1641 PB ltype, lpend
To: BUG-e, BUG-lisp
It would sometimes be nice to do *both* (when the viewing window is not
at end, but you want a record).
∂10-Jul-82 1846 Jerry Roylance <GLR at MIT-AI> (OPEN 'FOO '(APPEND)) on TOPS-20
Date: 10 July 1982 21:43-EDT
From: Jerry Roylance <GLR at MIT-AI>
Subject: (OPEN 'FOO '(APPEND)) on TOPS-20
To: BUG-LISP at MIT-AI
cc: GLR at MIT-AI
(OPEN 'FOO '(APPEND)) on TOPS-20 does not allow random access on the opened file.
The code opens the file in OF%APP (append mode) which
TOPS-20 must interpret as allowing only writes to the end of the file
and enforces that by prohibiting the user from moving the filepos.
The appropriate mode (see the OPENF JSYS) is OF%RD+OF%WR (read and write = update).
Changing
OPEN3E+2/ TRC 2, OF%APP+OF%WR+OF%RD
to
OPEN3E+2/ TRC 2, OF%RD
allows random access.
Would somebody please make this change or tell me how to do it?
Do I just edit MC:L;QIO > ?
Jerry
∂12-Jul-82 1137 JonL at PARC-MAXC Re: (OPEN 'FOO '(APPEND)) on TOPS-20
Date: 12 Jul 1982 11:11 PDT
From: JonL at PARC-MAXC
Subject: Re: (OPEN 'FOO '(APPEND)) on TOPS-20
In-reply-to: GLR's message of 10 July 1982 21:43-EDT
To: Jerry Roylance <GLR at MIT-AI>
cc: BUG-LISP at MIT-AI
Sure, editing MC:L;QIO > is the first step. Canonical Twenex sources
used to be kept on [XX]SS:<MACLISP>, and the Twenex .EXE file
produced by submitting PS:<MACLISP>ASSLISS.CTL -- but maybe
sinze OZ is coming alive, the "canonical" place may be there. What
about it ALAN, will you oversee this?
Minor note: your suggested change probably wanted
OPEN3E+2/ TRC 2, OF%WR+OF%RD
instead of
OPEN3E+2/ TRC 2, OF%RD
didn't it?
∂23-Jul-82 1446 Guy.Steele at CMU-10A MacLISP
Date: 23 July 1982 1723-EDT (Friday)
From: Guy.Steele at CMU-10A
To: rwk at MIT-MC, gjc at MIT-MC
Subject: MacLISP
CC: bug-lisp at MIT-MC
- - - - Begin forwarded message - - - -
Mail-From: ARPANET host MIT-MC received by CMU-10A at 23-Jul-82 15:36:45-EDT
Date: 23 Jul 1982 1139-EDT
From: SCHRAG at RADC-TOPS20
Subject: MacLisp for TOPS-10
To: GLS at MIT-MC
I am trying to acquire a version of MacLisp that will run under
TOPS-10 (version 6.03). Syracuse University has a contract with
RADC to develop a programming environment called LOGLISP, which
is a synthesis of LISP and logic programming. To date they have
developed the system in UCI-LISP, but plan to move to LISP
machines later this year. We hope that MacLisp will be a good
vehicle for development in the interim, its being closer to
LISP machine LISP than UCI-LISP.
I have communicated with Scott Fahlman and Dave Touretzky
at CMU--they have given me pointers to the CMU "MacLisp
environment," which I have ftp'ed. Dave suggested that since
CMU's versions of MACLSP and COMPLR are modified for their
"modified" TOPS-10 system, I should obtain these files from
MIT on "distribution tape." Syracuse is not on the ARPANET,
and I am planning to make a tape for them of MacLisp files.
Would it be possible to obtain these files via ftp, and save
the trouble of making and mailing a tape?
Thank you for your attention.
Bob Schrag
RADC/COAD
-------
- - - - End forwarded message - - - -
∂24-Jul-82 1332 Glenn S. Burke <GSB at MIT-ML> macro/function competition
Date: 24 July 1982 16:31-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: macro/function competition
To: KMP at MIT-MC
cc: BUG-COMPLR at MIT-MC
A better way to handle this, and what is apparently the reason perturbations
of this code have not shafted me, is to use the source-trans instead.
This then introduces an ordering problem if what you want is a least-preferred
source-trans...
The code that produces this diagnostic in COMPLR is highly suspect. In
particular it calls P1KNOWN on an incorrect argument. It checks
for a DEFCOMPLRMAC property to bypass the diagnostic. However as far
as i can tell, that property is only put on by the DECOMPLRMAC macro,
which does not seem to do this defsubst-like stuff, i.e., that is
not a valid test to bypass the diagnostic on. (DEFCOMPLRMAC appears
to be sort of a DEFMACRO that does (eval-when (eval compile load-but-only-
when-in-the-compiler) ...).) I will probably look at this some and fix
it in the source.
∂24-Jul-82 2259 George J. Carrette <GJC at MIT-MC> MacLISP
Date: 25 July 1982 02:00-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: MacLISP
To: SCHRAG at RADC-TOPS20
cc: BUG-LISP at MIT-MC, RWK at MIT-MC, Guy.Steele at CMU-10A
Considering the trouble of running under TOPS-10, well, Maclisp
just isn't that close to lispmachinelisp. Can you get your hands on
a VAX-750? Right now I'm working over the summer with another
guy from MIT in a VAX-VMS-NIL environment on a 750 that the company
was able to rent quite quickly for the summer months. We brought up
code originally written on a lispmachine without hassle, and expect
to be able to port back easily too. (Actually, the same thing
was true with the Macsyma port to NIL, conditionalizations which
were #+LISPM could just be changed to #+(OR LISPM NIL), the
initial port taking 4 days due to this "lucky-break," whereas
both the PDP-10 Maclisp and Franz conditionalizations indicate
something really out of a different genre.)
My experience is that this is the minimum-time minimum-hassle solution.
∂25-Jul-82 0032 Dave Touretzky at CMU-10A Re: MacLISP
Date: 25 July 1982 0329-EDT
From: Dave Touretzky at CMU-10A
To: George J. Carrette <GJC at MIT-MC>
Subject: Re: MacLISP
CC: schrag at radc-tops20, bug-lisp at MIT-MC, rwk at MIT-MC,
Guy Steele at CMU-10A
In-Reply-To: George J. Carrette@MIT-MC's message of 25 Jul 82 01:00-EST
Nonsense. You've misunderstood Mr. Schrag's problem. The people at Syracuse
want to write code in a clean and simple Lisp dialect that they can then
move to a Lisp Machine. They are currently working in UCI Lisp. If they
wrote equivalent code in Maclisp it would be trivial to move to the Lisp
Machine.
These guys do not need to know about #+ conditionalizations or any of the
other esoteric psuedo-Lisp Machine cruft that's been added to MacLisp in
the last few years. Give them a distribution tape and tell them to say
DEFUN instead of DE, and I'm sure they'll be happy.
-- Dave Touretzky
∂25-Jul-82 1106 Dick@MIT-AI
Date: Sunday, 25 July 1982 14:03-EDT
Sender: DICK at MIT-OZ
From: Dick@MIT-AI
To: bug-lisp at MIT-AI
The following will not compile because the let tries to bind the I to
NIL! LET should check and make sure that it binds each arg to
something of the correct type when it is defaulting like this.
(declare (fixnum i))
(defun foo ()
(let (i)
(setq i (read))
(print i)))
-------
∂25-Jul-82 1740 David Vinayak Wallace <GUMBY at MIT-AI> JSYS calls under twenex maclisp
Date: 25 July 1982 20:02-EDT
From: David Vinayak Wallace <GUMBY at MIT-AI>
Subject: JSYS calls under twenex maclisp
To: INFO-LISP at MIT-AI
How can I access values returned in random registers after a jsys call
(i.e "returns +1 if unsuccessful, error code in acc 2")?
david
∂25-Jul-82 2131 George J. Carrette <GJC at MIT-MC> JSYS calls under twenex maclisp
Date: 26 July 1982 00:14-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: JSYS calls under twenex maclisp
To: GUMBY at MIT-AI
cc: BUG-LISP at MIT-MC
INFO-LISP is not the place to ask for information about lisp,
it is the place to send information about lisp. BUG-LISP
is a better handle on lisp hackers. Anyway, what you
need to do is learn about LAP, lisp assembly programming,
and the conventions used by the compiler. Under some
conditions you may be able to get away with using (EXAMINE 2)
for example to get the contents of register 2.